avoid flushing keys db queue after each Annex action

The flush was only done Annex.run' to make sure that the queue was flushed
before git-annex exits. But, doing it there means that as soon as one
change gets queued, it gets flushed soon after, which contributes to
excessive writes to the database, slowing git-annex down.
(This does not yet speed git-annex up, but it is a stepping stone to
doing so.)

Database queues do not autoflush when garbage collected, so have to
be flushed explicitly. I don't think it's possible to make them
autoflush (except perhaps if git-annex sqitched to using ResourceT..).
The comment in Database.Keys.closeDb used to be accurate, since the
automatic flushing did mean that all writes reached the database even
when closeDb was not called. But now, closeDb or flushDb needs to be
called before stopping using an Annex state. So, removed that comment.

In Remote.Git, change to using quiesce everywhere that it used to use
stopCoProcesses. This means that uses on onLocal in there are just as
slow as before. I considered only calling closeDb on the local git remotes
when git-annex exits. But, the reason that Remote.Git calls stopCoProcesses
in each onLocal is so as not to leave git processes running that have files
open on the remote repo, when it's on removable media. So, it seemed to make
sense to also closeDb after each one, since sqlite may also keep files
open. Although that has not seemed to cause problems with removable
media so far. It was also just easier to quiesce in each onLocal than
once at the end. This does likely leave performance on the floor, so
could be revisited.

In Annex.Content.saveState, there was no reason to close the db,
flushing it is enough.

The rest of the changes are from auditing for Annex.new, and making
sure that quiesce is called, after any action that might possibly need
it.

After that audit, I'm pretty sure that the change to Annex.run' is
safe. The only concern might be that this does let more changes get
queued for write to the db, and if git-annex is interrupted, those will be
lost. But interrupting git-annex can obviously already prevent it from
writing the most recent change to the db, so it must recover from such
lost data... right?

Sponsored-by: Dartmouth College's Datalad project

update

all keys are still present on versioned remote after import of a tree

When importing from versioned remotes, fix tracking of the content of
deleted files.

Only S3 supports versioning so far, so only it was affected.

But, the draft import/export interface for external remotes also seemed to
need a change, so that versionedExport could be set.

S3: pass fileprefix into getBucket calls

S3: Speed up importing from a large bucket when fileprefix= is set by only
asking for files under the prefix.

getBucket still returns the files with the prefix included, so the rest of
the fileprefix stripping still works unchanged.

Sponsored-by: Dartmouth College's DANDI project

future proof AWS.Credentials generation

Avoid breaking when a field is added to the constructor.

Sponsored-by: Dartmouth College's DANDI project

take lock in checkLogFile and calcLogFile

move: Fix openFile crash with -J

This does make them a bit slower, although usually the log file is not
very big, so even when it's being rewritten, they will not block for
long taking the lock. Still, little slowdowns may add up when moving a lot
file files.

A less expensive fix would be to use something lower level than openFile
that does not check if the file is already open for write by another
thread. But GHC does not seem to provide anything convenient; even mkFD
checks for a writing thread.

fullLines is no longer necessary since these functions no longer will
read the file while it's being written.

Sponsored-by: Dartmouth College's DANDI project

fix typo

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

Added a comment

removed

Added a comment

Added a comment

initial report on locking issue on move

update

Added a comment

comments

add missing whitespace in warning message

comment

improve usage

These commands operate on not only remotes, but any way a repository can
be specified, including "here" etc.

Sponsored-by: Graham Spencer on Patreon

avoid combining multiple words provided to trust/untrust/dead

* trust, untrust, semitrust, dead: Fix behavior when provided with
  multiple repositories to operate on.
* trust, untrust, semitrust, dead: When provided with no parameters,
  do not operate on a repository that has an empty name.

The man page and usage already indicated that multiple repos could be
provided to these commands, but they actually used unwords to combine
everything into string, and found a repo matching that string. This was
especially bad when no parameters resulted in the empty string and some
repo happened to have an empty description.

This does change the behavior, and it's possible someone relied on the
current behavior to eg, trust a repo by name with the name not quoted into
a single parameter. But fixing the empty string bug and matching the
documentation are worth breaking that usage.

Note that git-annex init/reinit do still unwords multiple parameters when
provided to them. That is inconsistent behavior, but it certianly seems
possible that something does run git-annex init with an unquoted
description, and I don't think it's worth breaking that just to make it more
consistent with these other commands.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

improve wording

This is to improve this case:

joey@darkstar:~/tmp/yyyy>git-annex trust
git-annex: no remote specified

The command does not need to be run with a remote, any repository name
will do, including eg "here".

Sponsored-by: Brock Spratlen on Patreon

add news item for git-annex 10.20221003

releasing package git-annex version 10.20221003

change name of option

See https://bugs.debian.org/885987

bug report

Added a comment

Added a comment: restage.log was empty indeed

Merge branch 'master' of ssh://git-annex.branchable.com

add comments

applied a patch

Fix annex.adviceNoSshCaching having no effect

git will always return option names in lowercase

fix flush of a closed file handle

Avoids displaying warning about git-annex restage needing to be run in
situations where it does not.

Closing a handle flushes it anyway, so no need for an explict flush. The
handle does get closed twice, but that's fine, the second one does nothing.

Sponsored-by: Dartmouth College's DANDI project

comment

update in response to comment

comment

reporting that we're now in some cases needlessly reminded to run `restage`

Added a comment: mess up commited to my branch

Added a comment

Added a comment: DIRHASH ending in slash?

Added a comment

Added a comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment

comment

Added a comment

v10nfs-bug

add news item for git-annex 10.20220927

releasing package git-annex version 10.20220927

remove link to closed todo

Not that it was actually fixed, but ..

avoid name shadowing warning

Support "inbackend" in preferred content expressions

Well, actually, fix a typo that has always been in the implementation of
that. "inbacked" used to work, but let's not tell users about that; they
might try to use it and expect git-annex to keep supporting the typo..

Sponsored-by: Jack Hill on Patreon

add comment

improve documentation about backends

I noticed that, using just the man pages, there is no real description
of what backends are, or what ones are available. Except for some
examples.

Added a git-annex-backends man page, that is just a stub, but at least
describes what they basically are, and tells how to find the supported
ons, and links to the backends web page.

Sponsored-by: Brett Eisenberg on Patreon

fix breakage in wormhole's sendFile

Commit ff0927bde98e7b7fd4a7ef49b61b8770c6df294d broke this, it made it
try to read all of the input before looking for the code. But, wormhole
keeps running until it sends the file, so that caused a deadlock. Oops.

Sponsored-by: Luke Shumaker on Patreon

fix wormhole --appid option position

p2p: Pass wormhole the --appid option before the receive/send command, as
it does not accept that option after the command

I'm left wondering, did I get this wrong from the beginning, or did
wormhole change its option parser? I'm reminded of the change in 0.8.2
where it silently changed what FD the pairing code was output to.
But, looking at the wormhole source, it was at least putting --appid before
send in its test suite from the introduction of the option.

So I think probably this has always been broken. On 2021-12-31 the --appid
option was enabled, and it took until now for someone to try
git-annex p2p --pair and notice that flag day broke it..

Sponsored-by: Svenne Krap on Patreon

enable-tor: Fix breakage caused by git's fix for CVE-2022-24765

This relies on bfa451fc4e621700883fb3b34600bdf71f515a62 and is a bit of an
ugly hack.

Sponsored-by: Noam Kremen on Patreon

pass --git-dir when reading git config when it was specified explicitly

Let GIT_DIR and --git-dir override git's protection against operating in a
repository owned by another user.

This is the same behavior other git commands have.

Sponsored-by: Jarkko Kniivilä on Patreon

Revert "fix comment"

This reverts commit c39b057b2daa3280c045d56d60b2c91a99a9c31b.

fix comment

comment

comment

changelog and close

note that hooks are also run when on a crippled filesystem now

remove unncessary do block

Left by Reiko's patch

Run freeze and thaw hooks on crippled filesystems

The user sets these hooks deliberately so they should always be run. For
example this allows hooks to be used to manage file permissions on NTFS
volumes in WSL1.

handle upgrading repositories initialized with --version=9

As was attempted earlier in the buggy commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85

Avoided the bug that had by making the upgrade log be updated after each
upgrade step. So, after upgrade from v8 to v9, the log is updated, and
so Upgrade.V9's timeOfUpgrade check will find that it was upgraded
recently and so won't let it skip ahead to v10.

Sponsored-by: k0ld on Patreon

changelog for problem fixed by earlier revert

comment

Revert "handle upgrading repositories initialized with --version=9"

This reverts commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85.

This commit accidentially caused repos that were initialized at v8 to
also upgrade to v10. There is nothing in the upgrade.log for such a
repo..

fix windows build

Merge branch 'master' of ssh://git-annex.branchable.com

report on windows FTBFS

Added a comment

Fix some markdown formatting problems

Add patches for WSL1

Fix WSL1 instructions

close bug "git commit smudges unncessarily"

Added a comment

refector for legibility

restage: New git-annex command, handles restaging unlocked files

This is much easier and less failure-prone than having the user run
git update-index --refresh themselves.

Sponsored-by: Dartmouth College's DANDI project

fix restaging of transferred files after stalldetection kicks in

Sponsored-by: Dartmouth College's DANDI project

add restage log

When pointer files need to be restaged, they're first written to the
log, and then when the restage operation runs, it reads the log. This
way, if the git-annex process is interrupted before it can do the
restaging, a later git-annex process can do it.

Currently, this lets a git-annex get/drop command be interrupted and
then re-ran, and as long as it gets/drops additional files, it will
clean up after the interrupted command. But more changes are
needed to make it easier to restage after an interrupted process.

Kept using the git queue to run the restage action, even though the
list of files that it builds up for that action is not actually used by
the action. This could perhaps be simplified to make restaging a cleanup
action that gets registered, rather than using the git queue for it. But
I wasn't sure if that would cause visible behavior changes, when eg
dropping a large number of files, currently the git queue flushes
periodically, and so it restages incrementally, rather than all at the
end.

In restagePointerFiles, it reads the restage log twice, once to get
the number of files and size, and a second time to process it.
This seemed better than reading the whole file into memory, since
potentially a huge number of files could be in there. Probably the OS
will cache the file in memory and there will not be much performance
impact. It might be better to keep running tallies in another file
though. But updating that atomically with the log seems hard.

Also note that it's possible for calcRestageLog to see a different file
than streamRestageLog does. More files may be added to the log in
between. That is ok, it will only cause the filterprocessfaster heuristic to
operate with slightly out of date information, so it may make the wrong
choice for the files that got added and be a little slower than ideal.

Sponsored-by: Dartmouth College's DANDI project

generalize refreshIndex to MonadIO

Sponsored-by: Dartmouth College's DANDI project

avoid unncessary locking by checkLogFile

Like the comment says, this works without locking. It looks like I
originally copied another function and forgot to remove the locking.

Sponsored-by: Dartmouth College's DANDI project

add a finalizer to streamLogFile

Sponsored-by: Dartmouth College's DANDI project

refactor the restage runner

Sponsored-by: Dartmouth College's DANDI project